Always show emoji category tabs, decouple them from toolbar hiding - #2620

The reason for adding toolbar_hiding_global was that when the toolbar is hidden, the keyboard becomes shorter, and if the emoji or clipboard bars remain shown, the net viewing area becomes shorter.
We wanted to avoid changing keyboard height when switching modes, since that seemed visually unpleasant.
So we wanted to allow users to choose how to use the shorter space - less viewing area or no bars.
It had nothing to do with what the bar is used for. See discussion at the top of #1606.
BTW, one of the reasons for adding emoji navigation by swiping was in order to support this mode.

Thanks @eranl, that's a fair correction and I stand corrected — I framed this as "the bar is navigation, not a tool", but the actual rationale in #1606 was about height/space consistency when the toolbar is hidden, not about what the bar is for. Sorry for mischaracterising it.

To keep the discussion grounded, I measured what this PR actually does on an emulator (Pixel-ish, 1080×2400, toolbar hidden, 100% emoji size), using the IME window's contentTopInsets:

So you're right that this PR reintroduces a mode-switch height change — but only for the emoji view, and by exactly the category-bar height (~105 px). The clipboard view stays height-consistent (its bar now simply follows the toolbar). What the emoji view gains for that +105 px is: the full "no-bars" number of rows and the category bar, instead of today's either/or (bar + fewer rows, or more rows + no bar).

The reason I think that trade is worth it specifically for the emoji view: switching to emojis is usually a short, focused detour — you go there to pick an emoji and come back. In that moment, an extra visible row helps you find the emoji faster, and the temporarily taller keyboard is a very short-lived cost. It also sidesteps #2546, where a user simply couldn't find most emojis because, with the default settings, the only way to change category was swiping (which people don't discover). Relying on swipe-only navigation as the fallback is exactly what bit that user.

That said, I don't want to steamroll a deliberate decision, so it's really @Helium314's call. Roughly the options:

1. This PR as-is — category bar always shown as an on-top extension; emoji view is ~one row taller than the alpha keyboard, full rows preserved. (Accepts a height change, only in emoji view.)
2. Keep height constant — always show the category bar but let it eat into the grid (no height change, but back to ~3 rows). Fixes Can't find all list of emojis #2546's discoverability without the height jump, at the cost of a row.
3. Keep it configurable — but that's the setting this PR was trying to retire, so it adds back the complexity.

My preference (and the motivation from the linked discussion) is 1, because it's the only option that gives both discoverable category navigation and a full set of rows. But if the constant-height invariant is something you'd rather not break, 2 is a smaller change that still fixes the "can't find emojis" problem. Happy to rework the PR toward whichever direction you prefer.

Option 2 is already supported (the setting's default should possibly be changed to off, to prevent the issue you mentioned).
To make it totally configurable, you could replace the switch setting with a list setting with multiple options, but that could be confusing.
This feature has been out for over a year, so changing the way it works without an option, based on a single issue, seems problematic to me.